Via: UK.AC.EARN-RELAY; 16 OCT 89 10:58:21 GMT Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 6599; Sun, 15 Oct 89 22:13:04 BS Received: from CEARN.cern.ch by UKACRL.BITNET (Mailer X1.25) with BSMTP id 4741; Sun, 15 Oct 89 22:13:03 B Received: by CEARN (Mailer R2.03B) id 2128; Sun, 15 Oct 89 22:13:24 GVA Date: Sun, 15 Oct 89 15:00:11 MDT Reply-To: INFO-ATARI16@MIL.ARMY.WSMR-SIMTEL20 Sender: INFO-ATARI16 Discussion Comments: Warning -- original Sender: tag was INFO-A16@MARIST From: INFO-ATARI16-REQUEST@MIL.ARMY.WSMR-SIMTEL20 Subject: INFO-ATARI16 Digest V89 #523 Comments: To: INFO-ATARI16@WSMR-SIMTEL20.ARMY.MIL INFO-ATARI16 Digest Sun, 15 Oct 89 Volume 89 : Issue 523 Today's Topics: Laser C and FAST Problems SQL Database Access from C TOS problem ? ---------------------------------------------------------------------- Date: 15 Oct 89 19:16:59 GMT From: gem.mps.ohio-state.edu!usc!merlin.usc.edu!nunki.usc.edu!jjung@tut.cis.ohio-stat e.edu (John Jung) Subject: Laser C and FAST Problems I have a question for all you hard drive and Laser C owners out there. Recently, I got an ICD FAST 50 meg hard drive. It performs fine, with the exception that I can't run any software off the floppy (a 1040STfm) unless the hard drive is on, and I disable the HD (using Shift-Control-Alt). Other people have told me that the controller is a little flaky for this reason, but I'm not worrying about it much, because it's only a slight hassle. Now for my problem. I have Laser C 2.0 on the hard drive, and I use it fairly frequently. The problem is, whenever I do hard drive access with Laser C, occassionally, the mouse will die on me, in that I can't move the mouse pointer. Sometimes, the mouse's death is only minor, and I can use the keyboard controls to control the pointer and leave Laser C, and sometimes the death is major and nothing will move the mouse, in which case I simply have to reboot the whole system. I have noticed that before the mouse dies, a string of characters (same character in the string, but not the same character all the time) comes out on the active Laser C window, and then Laser C pops up a dialog saying that I should hit a key that is recognized by Laser C. Then the mouse dies. The mouse dying only happens with Laser C and not with other programs I use, like Flash! or WordUp!. I use Superboot 5.5A along with the other ICD utilities (clock and boot up program) to boot up my system. Also, I have no busy light (I can't get it to work), and the hard drive seems to do occassional disk access, but I'm not sure. What I want to know, is : Is this problem with Laser C common with other HD users? With other FAST users? Or is it that my HD controller is flakier than I thought, and that's what's causing all the problems (HD has to be on, to run floppy, random HD access, and Laser C mouse death)? Or do I have an HD virus? Please post or E-mail and help you can give. John ------------------------------ Date: 15 Oct 89 18:13:28 GMT From: galaxy.rutgers.edu!argus!ron@rutgers.edu (Ron DeBlock) Subject: SQL Database Access from C A few days ago, I promised to post an article demostrating how to use Regent Software's SQL Add-On with C. Sorry for the delay - my ST was at my dealer getting TOS 1.4 installed (yay!). I needed a cheap database for a school project, and I found SQL Add-On in E. Arthur Brown's catalog for $24.95. I preferred something I could use with Mark Williams C, but decided that GFA Basic would be OK. The SQL Add-On works well, but the documentation is not great and the SQL is not standard. Syntax is slightly different and it has a funky way of dealing with queries returning multiple rows. However, the price is right. Regent claims that files are compatible with RegentBase. It is supposed to work with GFA Basic V2 and V3. The Add-On is a terminate-and-stay-resident program (TSR). It loads the SQL processor and adds a new xbios call (xbios(500)). It takes up over 300 K of ram (buffers, I guess). To use the Add-On, run the TSR program first. Use GFA Basic's xbios() call to call xbios(500). This returns the address of the SQL processing function. The GFA Call function is then used to execute SQL statements. I reasoned that there is nothing preventing me from doing the same thing in Mark Williams C. In C, if you know the address of a function, you can call it. By reading the GFA Basic and MWC manuals, and spending some time with the MWC debugger, I worked it out. The SQL function expects two arguments on the stack: number of arguments (int, on top of stack) arguement buffer (pointer to array of pointers to char buffers) Below is a sample C program with comments. Feel free to email if you have questions (email may no work - post here or use snail mail in that case). Regent Software PO Box 14628 Long Beach, CA 90803-1208 (213) 439-9664 E. Arthur Brown 3404 Pawnee Drive Alexandria, MN 56308 (612) 762-8847 ----------------------------------------- /* Demonstration of using Regent SQL Add-On for GFA Basic with Mark Williams C. Copyright 1989 by Ronald J. DeBlock, Jr. May be used or distributed freely as long as this copyright notice is included. */ #include main() ? /* pointer to function */ typedef void (*PFI)(); extern long xbios(); /* sql is a pointer to a function returning void */ PFI sql; /* these char arrays hold arguments for the sql call */ /* fields */ char field1[21], field2[3], field3[21]; /* error code */ char error[10]; /* command string */ char command[100]; /* this array will hold pointers to the command, error and field arguments. Make the array larger if more fields are used. */ char *args[5]; /* the first field in the array points to SQL command string */ args[0] = command; /* second points to a buffer used to return error codes */ args[1] = error; /* all other fields point to buffers where the column results of a query will be placed - one buffer per culumn returned */ args[2] = field1; args[3] = field2; args[4] = field3; /* A program is run before the SQL Add-On can be used. It loads the SQL processor and creates a new xbios call. The new xbios call returns the address of the SQL processing routine. */ sql = (PFI)xbios(500); printf("sql = %U\n",(long)sql); /* This program assumes that a table has been created using the SQL statement CREATE TABLE phonelist name CHAR(20), age INT(2), phone CHAR(20); and some records have been added. The demo program included with the product (written in GFA Basic) will do this. */ /* set up the command string - SELECT [1] is Regent's funky way of setting up a cursor */ strcpy(command,"SELECT [1] * FROM phonelist;"); /* Call the SQL processor. The function expects to see the number of arguments on the top of the stack, followed by a pointer to the argument array. *** WARNING *** This is compiler dependent!! Mark Williams C pushes arguments right to left. Your compiler may differ. If so, reverse the order of the arguments and it should work. */ (*sql)(5,args); printf("error: %s\n",error); printf("%s %s %s\n",field1, field2, field3); /* execute another commend to retrieve the next row. SELECT NEXT is Regent's funky way of dealing with cursors */ strcpy(command,"SELECT NEXT * FROM phonelist;"); (*sql)(5,args); printf("error: %s\n",error); printf("%s %s %s\n",field1, field2, field3); ? ------------------------------------- -- Ron DeBlock N2JSO Net: ...!rutgers!galaxy!argus US Mail: 42 Davis Street, Phillibsburg, NJ 08865 USA ------------------------------ Date: 15 Oct 89 15:29:10 GMT From: mcsun!hp4nl!ruuinf!piet@uunet.uu.net (Piet van Oostrum) Subject: TOS problem ? I encountered a strange TOS behaviour (TOS 1.2): I Fcreate a file, then Fopen the same file (not very usual, I agree). I get two filehandles of course. I only use the second one, and write some bytes to the file. Finally I close the second handle, and forget to close the first one, (or close that last). Result: an empty file. If the first filehandle is closed first, no problem. My guess is that the close on the first filehandle (either implicit or explicit) remembers that nothing has been written on this handle, so the file should be empty (???) Note: the compiler has long ints (GCC). Any comments? Is this a bug? Here is the program: ------------------------------------------------------------------------ #include char fname[] = "test.fil"; char message[] = "this is a line\n"; main() ? int fd1, fd2, r; fd1 = Fcreate(fname, 0); fd2 = Fopen(fname, 1); r = Fwrite(fd2, strlen(message), message); printf ("fd1=%d,fd2=%d,result=%d\n",fd1,fd2,r); Fclose (fd2); Fclose (fd1); /* or just delete this line */ ? -------------------------------------------------------------------------- Piet van Oostrum, Dept of Computer Science, University of Utrecht Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-531806 Internet: piet@cs.ruu.nl Telefax: +31-30-513791 Uucp: uunet!mcsun!hp4nl!ruuinf!piet ------------------------------ End of INFO-ATARI16 Digest V89 Issue #523 *****************************************